失敗から学ぶ RDBの正しい歩き方
https://gyazo.com/b3f82d50f1776449a81f6041a794c230
RDB正直苦手だしキャリアの中で真面目にやってこなかったので読んだ
やり過ぎたJOIN
ジョインについての解説がけっこう厚めで助かる
NLJ, Hash Join, Sort Merge Join など未知だった
効かないINDEX
BTree についてはよく聞くので体系的に理解したというより毎度調べて理解した気になるやつをやってる
なのでデータ量やレコードに占める割合によりINDEXを効かせるより普通にテーブルスキャンのほうが速い、みたいな解説を読んで全然知らなかった、となった
tkdn.icon 今のところ5割も理解できない
フラグの闇: 親の顔より見たdelete_flag, status などもよくある状態を持つなというやつに含まれる
ソートの依存
ここでようやくORDER BY狙いのINDEXが理解できた
一方でOFFSETによるページャー実現ではなく前回取得のidなどをWHERE句に使うことも有効(INDEXが効く前提)
隠された状態
EAV, ポリモーフィック関連もまた類似したアンチパターン。正規化し交差テーブルをつくりましょう
JSONの甘い罠
何でもいれるはNG. 成功事例としては、外部APIのレスポンスのスナップショットとして、またはCMSのプラグインテーブルにおける各プラグインの設定項目の保存など
強すぎる制約
PostgreSQL DOMAIN型を使った制約でemail_address型を作ったものの、RFC準拠しないメールアドレスを許容できなくなっているというアンチパターン。早すぎる最適化として紹介されている MySQLにおける外部キーを持つ子の更新時に親テーブルにも共有ロックを取るという例 知らないロック
MySQLとPostgreSQLのロックの違いについて。
kamipoさんのブログがイメージしやすい(ネクストキーロックのロック範囲イメージ) code:image.txt
(negative infinity, 10]
(10, 11]
(11, 13]
(13, 20]
(20, positive infinity)
tkdn.icon PostgreSQL において ALTER TABLE では明示しないかぎり ACCESS EXCLUSIVE という一番強いロックがかかるというのも、最近実務で知った知識
Only an ACCESS EXCLUSIVE lock blocks a SELECT (without FOR UPDATE/SHARE) statement.
このロックは他のセッションからのテーブル参照である SELECT に対してもロックをかける唯一のロック
ロックの功罪
簡単すぎる不整合
非正規化の話。適切に正規化しないままだと予期せぬデータも入る
CHECK 規約、ENUM型で制約をもうける方法もある。が、正規化できる場合はするに越したことはない
複雑なクエリ
無知による剛腕で生まれる場合と、テーブル設計が腐って生まれる場合がある
キャッシュ中毒
キャッシュは麻薬
フレームワーク依存症
特にActiveRecordなんかが代表格。すべてを預けると死ぬ
前者は参照整合性がなくなるなどもちろん選択した場合のデメリットもある
後者はデザインパターンをフレームワーク内でうまく扱えるようにするパターン
ポリモーフィック関連と違い、STI そのものアンチパターンではない